These ActiveRecord models map onto the Heroku Connect-managed tables
(classroom__c, lesson__c, contact_classroom_affiliation__c) in the
salesforce_connect database. Each declares its external-ID field, hides
the Heroku-Connect-only sfid / _hc_lastop / _hc_err columns, and exposes
Salesforce field accessors derived from the editor-api parent record so
sync jobs can assemble payloads without leaking column names.

Factories included for use in the upcoming sync-job specs.

Pure data layer; nothing in the app references these models yet.

Co-authored-by: Cursor <cursoragent@cursor.com>

Three new GoodJob-backed sync jobs follow the established
SalesforceSyncJob pattern (mapped attributes + truncation + concurrency
keyed on the source record id):

  Salesforce::SchoolClassSyncJob   -> Classroom__c
  Salesforce::ClassTeacherSyncJob  -> Contact_Classroom_Affiliation__c
  Salesforce::LessonSyncJob        -> Lesson__c

Each calls ensure_parent_synced! before saving so the new __r__
external-ID lookups can't permanently FAIL on a parent that hasn't
landed yet; the base class retry handles redelivery.

Adds matching rake tasks (salesforce_sync:school_class,
salesforce_sync:class_teacher, salesforce_sync:lesson) so backfill stays
consistent with the existing school/role/contact pattern.

Includes a shared not_have_enqueued_job negated matcher in spec/support
for use by the upcoming callback specs.

No model callbacks yet -- jobs are wired up in the next commit.

Co-authored-by: Cursor <cursoragent@cursor.com>

Hook the new sync jobs onto the editor-api model graph. Each callback is
guarded by FeatureFlags.salesforce_sync? so dev/test stay quiet by
default.

  SchoolClass             -> SchoolClassSyncJob on create/update
  Lesson                  -> LessonSyncJob on create/update (class-bound)
  ClassTeacher            -> ClassTeacherSyncJob on create;
                             SchoolClassSyncJob on create/destroy
                             (refreshes numberofmembers__c)
  ClassStudent            -> SchoolClassSyncJob on create/destroy
                             (numberofmembers__c only -- no per-lesson
                             cascade; remix Project creation drives
                             lesson syncs instead)
  Project (remix)         -> LessonSyncJob on create
                             (numberofassignedprojects__c is exactly
                             remixes.count, which only changes here)
  SchoolProject (state)   -> recalculate submitted_projects_count and
                             enqueue LessonSyncJob on transitions
                             into/out of :submitted and :complete

Brand-new classes race SchoolClassSyncJob vs. ClassTeacherSyncJob; the
race is harmless because ensure_parent_synced! defers the child write
until the parent lands and per-record concurrency on the base job
collapses duplicate enqueues.

Includes model specs (school_class, lesson, class_teacher,
class_student, project) and the negated_matchers helper to assert
"on enqueue X and explicitly not Y" with compound expectations.

Co-authored-by: Cursor <cursoragent@cursor.com>

Scratch projects are the primary focus of this Salesforce work but they
don't transition through the SchoolProject state machine -- Experience
CS marks them complete by flipping school_projects.finished via
Concept::SchoolProject::SetFinished. Without a separate path the
Statesman-driven submitted_projects_count would miss every Scratch
completion and Lesson__c.numberofcompletedprojects__c would be 0 for
any Scratch-only lesson.

  * Lesson#finished_projects_count: live read of school_projects.where(
    finished: true).count. Not cached because its only consumer is the
    per-lesson concurrency-limited LessonSyncJob; the recalc-on-write
    machinery used for submitted_projects_count would be overkill here.

  * LessonSyncJob: numberofcompletedprojects__c now sums
    submitted_projects_count + finished_projects_count. The two flows
    are mutually exclusive in practice, so a plain sum is safe.

  * SchoolProject after_commit on saved_change_to_finished?: enqueue
    LessonSyncJob so the Salesforce mirror updates when Experience CS
    flips the flag. Statesman-driven transitions remain handled by the
    state-machine after_transition callback wired in the previous
    commit.

Recalculation of submitted_projects_count is unchanged: it still counts
only Statesman :submitted rows, keeping the two flows independent.

Co-authored-by: Cursor <cursoragent@cursor.com>

Capture the operational shape of the sync layer for future agents:
where data goes (salesforce_connect DB, not the Salesforce API), how
it's gated (SALESFORCE_ENABLED), the backfill ordering, and -- most
importantly -- the parent-sync race guard that every job using __r__
external-ID lookups has to call before writing.

Heroku Connect's permanent-FAIL behaviour on missing parents is a
non-obvious failure mode; the doc names ensure_parent_synced!, points
at the retry policy on the base class, and lists the call sites so the
pattern stays consistent as more sync jobs are added.

Co-authored-by: Cursor <cursoragent@cursor.com>